It is increasingly common for software vendors to include open-source software (OSS) components in their products, incorporating functionalities contributed by the open-source community, in an effort to reduce development and maintenance costs. However, security vulnerabilities that affect such OSS components are inherited by the products that incorporate them. Despite its apparent simplicity, determining what fixes are necessary and effectively applying them turns out to be a difficult problem. In order to address this problem, software vendors are establishing processes to ensure that their entire software supply chain is secured. These processes include tracking and monitoring all OSS components imported as well as reacting to vulnerability disclosures with the timely application of patches.
Despite these efforts, maintaining a healthy code base is still a challenging task. Indeed, the number of OSS components included, even in moderately sized projects, can be unwieldy. While the direct dependencies of a software project can be just a few dozen, these, in turn, bring into the project additional transitive dependencies. As a result, it is not unusual for a software project to embed hundreds of OSS components. The large amount of legacy software in operation and that includes OSS components, whose identity and version is not systematically tracked, makes things even worse.